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METHOD AND APPARATUS FOR credit authorization, the gateway may not be able to discon- 

AUTHORIZATION BASED PHONE CALLS IN nect the call in a timely manner. 

PACKET SWITCHED NETWORKS Thus, the need remains for improving the scalability and 

reliability of authorization based telephone systems. 

This Application claims benefit of Provisional Ser. No. 5 SUMMARY OF THE INVENTION 

60/100,208 filed Sep. 14, 1998. A 1t tU . f . # . , . 

^ A call authorization system moves authorization based 

FIELD OF THE INVENTION slate mamtenance fr° m a central authorization server to 

multiple gateways in a packet switched network. A simple 
This present invention relates generally to systems for authorization session protocol is used between the authori- 
supporting authorization based phone calls, and more par- zation server and the gateways that minimizes network 
ticularly to a distributed authorization based phone call md ^so releases the authorization server from main- 
system used in Voice Over IP networks. taining call states for open authorization based phone calls. 

The gateway receives an account identifier and an autho- 

BACKGROUND OF THE INVENTION rization request for establishing a phone call with an end- 

15 point in the packet-switched network. The gateway sends an 

Packet switched networks route voice traffic using a Voice authorization request message to the authorization server 

Over Internet Protocol (VoIP). VoIP allows telephone calls including the account identifier and the authorization 

to be carried over an Internet Protocol (IP) network between request. The authorization server uses the account identifier 

two telephones or computers. as an index for matching a user record in a user database. 

Authorization systems verify user authorization to par- 20 T& e authorization server sends back a response message 
ticular phone services before allowing the phone network to accepting the authorization request if a user record verifies 
connect the call. The authorization system usually ^ authorization request. The gateway connects the call 
exchanges certain parameters between a Network Access when ^ authorization request is accepted and then mam- 
Server (NAS) that receives inputs from a user and an tai °f ^ authonzaUon states for the connected call If the 
authorization server that has access to a user database * authorization request is rejected by -the authorization server, 
containing authorization information for valid users. the terminates the authorization request. 

, iL . . . - . . . , . Scaling of the authorization system is improved since the 

Credit based authorization is one type of authorization ■ • , rtn n „ t „ f _ ^ 

, , , „ , T7 , A , j . . , . 4 . iL authorization server is freed from maintaining call states for 

based phone call. With credit based authorization, the user *u * *• u j n n l i 

r , . , . , . . , ' . # all open authorization based calls. Robustness is also 

sets up a debit accoimt with a telephone company prior to 30 im d because ^ authorization xry , r can crash and 

making phone calls The debit ^account often takes the form ^ bacR ^ a ^ ^ ^ &scomecU 

of a preapproved callmg card. When the user wishes to make i ■ n * . • c c n n 

u 11 *u *u • „• * *u * *u mg or losuig call state mformation for open calls. Because 

a phone call, the authorization system verifies that the user 7, . t . , . ,. u , , 4 * u . , 

, r rc-\ j-. ^ ii« j . L r call state mamtenance is distributed to multiple gateways, 

has sufficient credit on the calling card account before t . , 4 „ 4 & , „ 

4 , , ii * *u ii *i_ *i_ any one gateway can crash, and not affect credit based calls 

connecting the phone call. As the call continues, the autho- ^ o , ~, „ . „ 
. 4 . * * . i 4 I .35 estabusned through other gateways, 

rization system continuously tracks the cost of additional _ L . . . . , . . 

time of the call and subtracts the additional cost from the The "J^onzation session between the rathonzation 

remaining credit in the calling card account. The authoriza- s«verand *? ga ! ewa y 1S u USed f " a l anety of d , lffer ,f n ■ ,y P es 

lion system notifies the user when the credit limit is about to °. f ^onzaUon based phone calls For example, the inven- 

nin out on the calling card. If the user continues to talk past Uon . 1S " for ^edit based caUauthonzation such as 

the remaining credit limit, the authorization system termi- 40 m P mi , fcr P^,^ cards. Tte invention aUows the 

, _ J gateway to effectively "escrow" funds from the user account 

nates the phone call. ' lt . . J . . , . , . 

T - „ . , , , while the call is in progress, with a timer ticking down the 

In VoIP networks, a call is .established through the packet cscrow amount The authorization scrver ^ me cntirc 

switched network via a local gateway. A central authoriza- CSCT0Wcd out of ^ debit account If call 

Uon server in another part of the network tracks state 4S tetminates before ^ escrowed amount held at the gateway 

mformation regarding the authorization based call. State ^ ^ ^ rcmaini escrowed amount is "re-credited" 

information includes account identification information to me uscfs acc0UQt maintained by lhe authorization server, 

associated with the call, the rate for the current call, the ^ of maintaining ^ conducting ^ authoriza- 

elapsed time of the current call, the amount of credit tion statc proccssing in thc authorization server, the 

remaining on the prepaid calling card, etc. 50 escrowed amount ^ neld md ma i nta ined by the gateway and 

The authorization server keeps state information for all returned to the authorization server at the end of the call, 

open authorization based calls that go through the same nc invention is also used for destination based call 

authorization system. This centralized authorization system authorization where a particular call account is authorized to 

does not scale well. This is because all open authorization make calls 0Qly to preS pecified phone numbers. In another 

based calls are managed by the same authorization server. 55 application, the authorization session is used for class of 

There is also a reliability (robustness) problem with a service based call or quality of service authorization where 

centralized authorization server. If the authorization server call accounts are authorized for particular call services, such 

crashes, all open authorization based calls could be discon- ^ con f er ence calls 

nected. State information for all the open authorization ^ e fo ^ ^ Qther Qbj and advant 

based calls can also be lost when the authorization server 60 0 fthemvention will become more readily ar^arentfmm The 

crashes, creating accounting errors. following detailed description of a preferred embodiment of 

Another problem exists with tracking authorization based fa invention which proceeds with reference to the accom- 

call states from a central authorization server. The gateways panying drawings, 
that establish the call connections between two different 

endpoints are typically not prepared to respond to signals 65 BRIEF DESCRIPTION OF THE DRAWINGS 

sent asynchronously from the authorization server. Thus, if FIG. 1 is a functional block diagram illustrating a prior art 

the authorization server identifies a call exceeding a user's VoIP system. 
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FIG. 2 is a functional block diagram of the VoIP system authorization information, such as credit, destination and 
shown in FIG. 1 including an authorization system accord- class of service. The accounting system also allows account- 
ing to the present invention. ing messages to be reported in the middle of calls in addition 

FIG. 3 is a block diagram showing different types of to connect and disconnect times. This is useful in measuring 

authorization based phone calls supported by the authoriza- 5 long duration calls where is it desirable to update the credit 

tion system shown in FIG. 2. value for the user in database 20 at intervals during the call. 

FIG. 4 is a flow diagram showing how a gateway in FIG. J* 5 ^counting system supports multiple existing account- 
2 conducts an authorization session according to the present m S fonnats such as Automatic Message Account- 
invention, ing (AMA). 

FIG. 5 is a diagram showing the different messages sent 10 When a user at one of the phones 16, 24, 32 or 34 attempts 

between the gateway and an authorization server during the '° mak6 ■ authorization based VoIP call, such as a credit 

authorization session. based ^ me Mephom connects to one of the VoIP 

gateways in the network 12. For purposes of example, 

DETAILED DESCRIPTION OF THE assume that telephone 32 accesses gateway 26 in order to 

INVENTION 1S make a VoIP call to phone 16. 

FIG. 1 is a functional block diagram of a VoIP network 12. , 'f tead ° f routm S "» ^ through the authorization server 

The network 12 includes an Internet Protocol (IP) network " for authorization and call state management, the gateway 

22 connected to gateways 26 and 28, an authorization server ?. 6 "Jk*s««ouot m f onnatl ° n ™«* as acc °™ 1 «Je°tifica- 

14 and IP endpoints 16 and 24. Gateways 26 and 28 provide 20 U °V (A ?£L * P ass f word/ P eisonal u identification 

VoIP access between IP network 22 and a Public Switched numb " < P U IN > ^ a ™ ^"»t>™> is obtained from a 

Telephone Network (PSTN) 30. Authorization server 14 is ^ ^ '^ gateway 26 through an interface such as an 

connected to a backend billing system 18 that accesses a user Inte 6 ra ed ^ lce ^ nse < IVR > a PP" ca <^ ?» *™ 

database 20 application generates the voice prompts and retrieves the 

™™ T . , , «,™ T , • , Dua l Tone Multiple Frequency (DTMF) signals used by the 

PSTN 30 is connected to several PSTN endpoints, such as 25 gateway 26 to ^ acc0UQt and cal] ^ informa _ 

endpoints 32 and 34 which are standard circuit switched ^ IVR applications are ^ t0 mose skiUed m tne ^ 

telephones. Phones 32 and 34 access one another through ^ are not described in further detail. 

PSTN 30 and to endpoints 16 and 24 through gateways 26 ™ a ™-^ti> j htxt • * *■ n * j u , L 

j jin . i 1-1 m j • 4 j n xn Th e user ACCT ID and PIN information collected by the 

and 28 and IP network 22. IP endpoints 16 and 24 are IP ^ . iL A . ^ ... .. 

, IT1 . r IVR application in the gateway 26 is sent to authorization 

phones with VoIP service. 30 ™\ . a. • . ,« it _ . 

r server 14 dunng the authorization session 36. The authon- 

VoIP services are accessed from the phones 32 and 34 via zation XTVet u checks the ^ ACCT ID md piN against 

PSTN 30 or directly through the IP network 22 by IP phones information in the user database 20 in order to authenticate 

16 and 24. In the first case a phone connection involves me user call request Success or failure of the authorization 

dialing into an incoming gateway. Id both the PSTN and IP check ^ reported back m a response message from the 

Phone cases a connection mvolves a terminating gateway 33 authorization server 14 to the gateway 26. 

that eventually connects to a destination telephone. r* • ■ _* * * i. • *i. * *u *i_ • 

J r It is important to emphasize that the authorization server 

FIG. 1 shows how a credit based phone call was autho- 14 does not maintain calI states . In other wordS) tne autho . 
rized in earlier VoIP systems. Credit based calls, such as call rization server 14 no longer ^ required to continually track 
A and call B, would first have to be switched through the information, such as account information call duration and 
authorization server 14. The authorization server 14 would call destination for open calls in the IP network 22. The 
then maintain call states for both call A and call B during the authorization server 14 only has to verify, authorization 
duration of me call. Maintaining these call states comprised, requests and then send back response messages either 
among other things, identifying a specific account for the accepting or rejecting the authorization request. The gate- 
call, the destination for the call, the rate for the call and the ^ way 26 then controls when fanner processing is 
durauon of the call. required for that call by sending another request. 

As mentioned above, this centralized authorization sys- FIG. 3 shows different types of authorization based calls 

tem does not scale well because the authorization server 14 that are supported by the authorization system. A credit 

must manage states for all open authorization based calls in based authorization request 37 is used for credit based calls 

the packet switched network 22. There is also a reliability 5Q sucn ^ ±ox madc ^ prcpaid caUing cafds Adestilialion 

(robustness) problem. If the authorization server 14 crashes, based authorization request 38 is used when authorization is 

state information for all open authorization based calls (call based orj a particular or destination of the call such 

A and call B) is lost and the call charges are not debited as when a particular call account is only authorized to make 

correctly to the appropriate call account. calls to pre specified phone numbers. A class of service based 

Referring to FIG. 2, the present invention moves call state 55 authorization request 39 is used to authorize particular call 

management for the authorization based calls from the services, such as video conference calls. The authorization 

central authorization server 14 to the local gateways 26 and server 14 sends back a response message 35 that either 

28. The gateways 26 and 28 communicate with the autho- accepts or rejects the authorization request 37, 38, or 39. 

rization server 14 through authorization sessions 36. There Credit based authorization, destination based authorization 

are several protocols that can be used for conducting the 6Q and class of service based authorization are discussed in 

authorization session 36, such as RADIUS or DIAMETER. further detail below. 

Service Control Points (SCPs) 27 from the circuit FIG. 4 shows a flow diagram of a process 40 that executes 

switched telephone network 30 can also conduct authoriza- within gateway 26 or 28 during the authorization session 36. 

tion sessions 29 for call authorization. For simplicity, the process 40 is described below with 

The accounting system residing in backend billing office 65 respect to gateway 26. However, the process is applicable to 

18 supports call accounting and permits two way commu- any gateway in the VoIP network 12 that receives an 

nication with gateways 26 and 28 to allow queries for user authorization request from a user. 
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When a call request is received, the gateway 26 in step 42, 
initiates the IVR application to interface with the user. The 
IVR application in gateway 26 collects the user's ACCT ID 
and PIN information in step 44 by prompting the user and 
then monitoring the user responses. Gateway 26 sends the 5 
ACCT ID and PIN to authorization server 14 in step 46 for 
authentication. 

In step 47, gateway 26 waits for the response from 
authorization server 14. The authorization server 14 uses the 
ACCT ID and PIN to authenticate the call in the user l" 
database 20 through backend billing office 18 (FIG. 2). If 
authentication fails in step 47 due to a bad PIN, bad ACCT 
ID, or a protocol error, control flow returns to step 44. The 
IVR application then prompts and collects the user infor- 
mation again. If the authorization server 14 is successful in 15 
authenticating the authorization information in user database 
20, control flow proceeds to step 48 to verify user authori- 
zation. 

If the user is authorized for the requested type of call, 
control branches at step 49 to step 50 where a timer is 20 
started. The timer keeps track of the call duration for 
accounting purposes. If the user is not authorized in step 49, 
then control branches to step 52 and the call is disconnected. 

Once the timer is started at step 50, gateway 26 waits for ^ 
the timer to expire or for the user to hang-up. If the timer 
expires, control branches at step 51 back to step 46 to 
determine if the user is authorized to continue the call past 
the currently authorized time period. The user account 
information may have been updated since the timer origi- 3Q 
nally started. For example, credit for additional time may 
have been added to user account. 

If the user hangs-up, control branches at step 51 to step 52 
where the gateway 26 terminates the connection with the 
user and releases the connection resources. The gateway 35 
then sends an accounting message at step 54 to the autho- 
rization server 14 including the usage information for the 
call. The usage information is forwarded to the backend 
billing office 18 where the user account information is 
updated in the user database 20 to reflect the reported usage. 40 

As mentioned above, authorization of the user account in 
step 49 can take a number of different forms, such as credit 
based authorization, destination based authorization and 
class or quality of service (QoS) authorization. 

FIG. 5 shows the messages sent between the gateway 26 45 
and the authorization server 14 during the authorization 
session 36 and the information that may be contained in a 
user record 78 in database 20. 

The authorization server 14 and backend billing office 18 
(FIG. 2) comprise an integrated billing system with an 50 
authorization front end. The billing system running in back- 
end billing office 18 updates credit values according to user 
credit and usage. Backend billing systems are known to 
those skilled in the art and are, therefore, not described in 
further detail. 55 

In credit based authorization, the authorization server 14 
is integrated with software in the backend billing office 18 
and is configured to return authorization attributes that the 
gateway 26 uses to track user credit real time. The backend 6Q 
billing office 18 has real time access to user database 20 
which contains user records. 

Credit Based Authorization 

Credit based authorization is used to process credit based 65 
VoIP phone calls. The invention allows the gateway 26 to 
effectively "escrow" funds from the user account in user 
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database 20 while the call is in progress. The authorization 
server 14 takes the escrow amount out of the user's debit 
account in the user database 20. A timer 73 then ticks down 
the escrow amount during the phone call. If the call termi- 
nates before the amount escrowed to the gateway 26 is used 
up, the remaining escrow amount is "re-credited" to the 
user's account. 

An authorization request message 62 contains the ACCT 
ID, the PIN and authorization request provided by the user 
via the IVR application in the gateway 26. The gateway 26 
sends the authorization request message 62 to the authori- 
zation server 14. The authorization server 14 then uses the 
user data 64 including the ACCT ID and PIN from the 
authorization request message 62 to access a debit account 
in the backend billing office 18 (FIG. 2). If the ACCT ID in 
the user data 64 matches the ACCT ID 80 for a user record 
78 in the database and the PEN matches a PIN 82 in the user 
record 78, an authorization response message 68 accepting 
the authorization request is sent back to the gateway 26. 

An escrow credit value in response message 68 deter- 
mines the maximum amount of time a user has for staying 
connected on a call. The escrowed credit value is carried 
back to the gateway 26 from the authorization server 14. The 
gateway 26 uses the credit value to determine how long the 
call can continue. The user is notified in a message 92 output 
from the IVR system 90 of the amount of available call time. 
The gateway 26 then establishes the call. 

The gateway 26 initializes the timer 73 to the available 
call time. The available call time escrowed to the gateway 26 
can be configured to be the sum total of all time that is 
available in the user debit account or a pre -determined credit 
unit. When the timer 73 expires, the escrowed credit value 
has run out. The gateway 26 can make another request to 
escrow funds from the user debit account or can terminate 
the call. The IVR 90 can be activated to play a warning 
message 94 to the user and provide a grace period before 
disconnecting the call. If a request is made to escrow 
additional funds, the gateway 26 sends an update message 
72 to the authorization server 14. The user debit account in 
the database 20 is accessed again to determine if the user has 
acquired additional credit. If additional credit is available, 
more credit is escrowed in a response message 74. 

If the user hangs up before the escrowed funds run out, the 
gateway 26 disconnects the call and sends an accounting 
message 76 back to the authorization server 14. The 
accounting message 76 identifies any remaining amount in 
the escrowed funds. The authorization server 14 sends the 
usage information in the accounting message 76 back to the 
billing office 18 (FIG. 2) which in turn updates the user debit 
account in database 20. 

Destination Based Authorization 

Destination based Authorization is used to authorize calls 
based on a specified destination address. For destination 
based authorization, the user record 78 in user database 20 
includes one or more destination addresses 86 that a user is 
authorized to connect to. 

The destination address requested by the user is passed 
from the gateway 26 to the authorization server 14 along 
with the user's ACCT ID and PIN in the authorization 
request message 62. The authorization server 14 uses the 
ACCT ID, PIN and destination address in the user data 64 
to query the user database 20. If a user record 78 in database 
20 matches the ACCT ID and PIN and contains the 
requested destination address, the authorization server 14 
accepts the destination request. The response message 68 
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sent back to the gateway 26 indicates the destination address 
request has been accepted. The destination address 86 can be 
implemented as an array, a linked list, a TRIE, or other data 
structure of multiple address attributes to allow authoriza- 
tion for multiple destinations. 

Based on the response message, the gateway 26 connects 
or terminates the call connection requested by the user. In a 
similar way to credit based authorization, the IVR applica- 
tion 90 in the gateway 26 can prompt the user for user 
account and connection information, as well as play out a 
message reporting the result of the destination address 
request. For example, if the user is not authorized to connect 
to the requested destination, the IVR 90 can play a message 
96 notifying the user that a call to the requested address is 
not authorized. 

In one example of destination based authorization, 
employees (i.e. users) of a company are only permitted to 
make calls to the number (i.e. the destination address) of 
company headquarters and the usage charges are billed 
directly to the company. User records are inserted into the 
user database 20 for each employee that include the 
employee ACCT ID and PIN. The user records in database 
20 indicate the employee is permitted access only to the 
destination address of the company headquarters. 

The destination address requested by the employee is sent 
from the gateway 26 to authorization server 14 in authori- 
zation request message 62. The authorization server 14 
queries database 20 and finds an entry for the employee. A 
successful database query is reported back by the authori- 
zation server 14 to gateway 26 which, in turn, establishes the 
call connection. After the call disconnects, the usage infor- 
mation is reported from the gateway 26 to the authorization 
server 14 in accounting message 76 and the company 
account is billed. 

Quality of Service Authorization 

The authorization session can also be used to authorize 
calls based on a requested class of service or quality of 
service (QoS). For class based authorization, the user record 
78 in user database 20 includes class(es) of service 88 that 
the user is permitted to use. 

During authorization, the class of service requested by the 
user is passed from the gateway 26 to the authorization 
server 14 along with the user's ACCT ID and PIN in the 
authorization request message 62. The authorization server 
14 queries user database 20 with the ACCT ID, PIN and 
class of service in user data 64. If a user record 78 is found 
in database 20 indicating that the user is authorized to 
connect with the requested class or service, the authorization 
server 14 sends back the response message 68 accepting the 
requested class of service. 

If the user record 78 indicates that the user is not autho- 
rized for the requested class of service, the response message 
68 rejects the class of service request. The class of service 
attribute 88 can be implemented as an array or a linked list 
of multiple class attributes to allow authorization of the user 
for multiple class values. 

Based upon the acceptance or denial of the call request, 
the gateway 26 establishes the call for the requested class of 
service or terminates the call request. In a similar way to 
credit and destination based authorization, the IVR applica- 
tion in the gateway 26 prompts the user for user account and 
connection information, as well as plays out a message 98 
notifying the user of the status for the requested class of 
service. 

As an example of class based authorization, a user sub- 
scribes to video conferencing services. The subscriber pays 
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a fee and is then permitted to make VoIP video conference 
calls. A user record is inserted into the user database 20 for 
the subscriber having the subscriber's ACCT ID and PIN 
and a class of service identifier 88 corresponding to video 
conferencing. 

The class of service requested by the user is sent from the 
gateway 26 to authorization server 14 along with the ACCT 
ID and PIN in the authorization request message 62. The 
authorization server 14 finds the user record 78 in the 
database 20 matching the ACCT ID, PIN and requested class 
of service. The successful database query is reported to 
gateway 26 in response message 68 which enables the 
gateway 26 to make the video connection. After the call 
disconnects, the usage information associated with the video 
conference is reported in accounting message 76 back to the 
authorization server 14 for billing to the subscriber. 

Other examples of classes of services are grades of voice 
(i.e. compression algorithm used), multi-party conferencing, 
call forwarding, and callerlD. These services are typically 
based upon the use of specific infrastructure required to 
support the class of service. 

Having described and illustrated the principles of the 
invention in a preferred embodiment thereof, it should be 
apparent that the invention can be modified in arrangement 
and detail without departing from such principles. For 
example, though the present invention is described in the 
context of credit, QoS and destination based authorization, 
it will be understood by those of ordinary skill in the art that 
the principles of the present invention can be applied to other 
authorization based calls. We claim all modifications and 
variations coming within the spirit and scope of the follow- 
ing claims. 

What is claimed is: 

1. A call authorization system for use in a packet switched 
network, comprising: 

a gateway receiving an authorization request for estab- 
lishing a phone call through the packet switched net- 
work; 

the gateway sending an authorization request message 
forwarding the authorization request and receiving 
back a response message either accepting the call and 
authorization request message or rejecting the call and 
authorization request, the response message accepting 
the call and authorization request including a credit 
value; 

the gateway connecting the phone call and maintaining 
authorization states for the connected phone call when 
the response message indicates the authorization 
request is accepted; 

the gateway sending another authorization request mes- 
sage during the connected phone call requesting addi- 
tional time when the credit value is about to be used up 
by the connected phone call; and 

maintaining the connected phone call when the response 
to the additional authorization request message pro- 
vides an additional credit value. 

2. A call authorization system according to claim 1 
wherein the gateway receives an account identifier from a 
user and transmits the account identifier in the authorization 
request message to an authorization server, the authorization 
server using the account identifier as an index for matching 
a user record in a database. 

3. A call authorization system according to claim 2 
wherein the account identifier comprises an account number 
and/or a personal identification number. 

4. A call authorization system according to claim 2 
wherein the response message indicates acceptance of the 
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authorization request when a user record in the database 
matches the account identifier and contains the authorization 
request in the authorization request message. 

5. A call authorization system according to claim 1 
wherein the response message includes a credit value from 5 
a user record matching the account identifier. 

6. A call authorization system according to claim 5 
wherein the gateway uses the credit value to initialize a timer 
for tracking duration of the connected phone call. 

7. A call authorization system according to claim 5 where 1Q 
the gateway reports the credit value and the duration of the 
call back to the user over an IVR system. 

8. A call authorization system according to claim 5 
wherein the gateway transmits an accounting message to an 
authorization system after the call is terminated, the account- 
ing message indicating a duration of the phone call. 15 

9. A call authorization system according to claim 8 
wherein the authorization system updates the credit value in 
the matching user record according to the call duration. 

10. A call authorization system according to claim 5 
wherein the gateway periodically transmits authorization 20 
request messages to the authorization server requesting 
updates to the credit value. 

11. A call authorization system according to claim 1 
wherein the authorization request message includes a des- 
tination address, the gateway connecting the call when the 25 
destination address is indicated as accepted by the response 
message. 

12. A call authorization system according to claim 2 
wherein a Radius protocol is used in the gateway and the 
authorization server for processing the authorization request. 3Q 

13. A call authorization system according to claim 1 
wherein the authorization states maintained by the gateway 
include tracking an account identifier for the call, a duration 
of the call, a connect status of the call, and accounting 
information for the phone call. 

14. A method for authorizing a user to access a phone 35 
network through a gateway, comprising: 

receiving a call connection request from a user, 

collecting an account identifier from the user, 

sending the account identifier and the call connection 4Q 
request from the gateway for authorization; 

connecting the call and maintaining authorization states 
with the gateway when a response message authorizing 
the call connection request is received by the gateway; 

receiving a credit value with the response message autho- 4S 
rizing the call connection request; 

sending another request from the gateway to extend the 
connected call when a call authorization period for the 
connected call is about to run out; and 

extending the connected phone call when another 50 
response message is received by the gateway authoriz- 
ing an additional call authorization period. 

15. A method according to claim 14 wherein the gateway 
connects the call for a time period corresponding to 
escrowed funds from a user debit account contained in the 55 
response message. 

16. A method according to claim 15 wherein the gateway 
periodically sends update messages requesting more 
escrowed funds from the debit account. 

17. A method according to claim 15 including notifying 60 
the user from time to time with the gateway as to what 
portion of the time period remains in the calL 

18. The method according to claim 15 including discon- 
necting the call when the user hangs up and sending an 
accounting message from the gateway identifying any 65 
remain portion of the escrowed funds to be recxedited to the 
debit account. 
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19. The method according to claim 14 including: 
sending a destination address in the call connection 

request; 

receiving the response message accepting the call request 
when a matching user record verifies the destination 
address; 

receiving the response message rejecting the call connec- 
tion request when there is no matching user record or 
the matching user record does not verify the destination 
address; 

connecting the call through the gateway when the 
response message accepts the call connection request; 
and 

terminating the call when the authorization message 
rejects the call connection request. 

20. An authorization server for authorization based call 
requests made in a packet switched network having a 
gateway, comprising: 

the authorization server receiving an authorization request 
message from the gateway including a call account 
identification and an authorization request; 
the authorization server using the call account identifica- 
tion as an index for matching a user record in a user 
database; 

the authorization server accepting the authorization 
request when a matching user record verifies the autho- 
rization request; 
the authorization server rejecting the authorization 
request when there is no matching user record or a 
matching user record does not verify the authorization 
request; 

the authorization server sending a response message back 
to the gateway enabling the gateway to connect and 
maintain authorization based states for the call when 
the authorization request is accepted and causing the 
gateway to terminate the call when the authorization 
request is accepted; 
the authorization server authorizing the call for a period of 
time with the response message accepting the authori- 
zation request; 
the authorization server receiving another authorization 
request from the gateway requesting authorization of 
the connected call for an additional period of time; and 
the authorization server sending out another response 
message authorizing the additional time period for 
maintaining the connected phone call when an account 
associated with the matching user record indicates 
available credit. 

21. An authorization server according to claim 20 wherein 
the response message contains a credit value obtained from 
the matching user record. 

22. An authorization server according to claim 20 wherein 
the authorization server verifies a destination address in the 
authorization request with the matching user record. 

23. A method for authorizing a user to access a phone 
netweork, comprising: 

receiving an authorization request message including an 

account identifier and a call connection request; 
querying a user database for a user record matching the 

account identifier; 
authorizing a call when contents in a matching user record 

correspond with the call connection request; 
rejecting authorization of the call when there is no match- 
ing user record in the user database or a matching user 
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record does not correspond with the call connection 
request; 

sending an authorization message that enables a gateway 
to connect the call when the call connection request is 
authorized and further enables the gateway to maintain 5 
authorization states for the call; 

sending an authorization message that causes the gateway 
to terminate the call when the call connection request is 
rejected; 

J 10 
sending a call credit value with the authorization message 

authorizing the connection request; 

receiving another authorization request from the gateway 

while the call is connected requesting an additional 

credit value for the connected call; 
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authorizing an additional period of time for maintaining 
the call when there is an available credit value in a 
matching user record; and 

sending an authorization message that enables the gate- 
way to maintain the connected call for a period of time 
associated with the available credit value. 

24. A method according to claim 23 including sending a 
credit value from the matching user record in the authori- 
zation message. 

25. A method according to claim 23 including verifying a 
destination address in the call connection request corre- 
sponds with the matching user record. 
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